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(S) System zur Statusabfrage von digitalen Zertifikaten 

(57) Die Erfindung betrrfft ein System zur Stauabfrage von 
digitalen Zertifikaten mit einer zentralen Zertifikatstatus- 
datenbank (4). Das Besondere der Erfindung besteht dar- 
in, da& eine Vielzahl von lokalen Ze rtifikatstatusd ate n ban- 
ken (12), die von auften zuganglich sind und als Datenbe- 
stand jeweils nur eine Teilmenge des Datenbestandes der 
zentralen Zertifikatstatusbank (4) enthalten, und eine Re- 
pliziereinheit (6, 8, 10} zum Abgleich des Datenbestandes 
der lokalen Zertifikatstatusdatenbanken (12) jeweils mit 
der entsprechenden Teilmenge des Datenbestandes der 
zentralen Zertifikatstatusdatenbank (4) vorgesehen sind. 
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Beschreibung 

j 0001] Die Erfindung betrifft ein System zur Statusab- 
lYage von digilalen Zertifikaten, mit einer zentralen Zerlifi- 
katstalusdalenbank. 5 
[0002] Aufgrund der weltweit sleigenden Teilnehmerzah- 
len in elektronische Netzen und insbesondere im Internet ist 
auch eine Zunahme von Waren und Dienstleistungen, die 
liber dcrartige elektronische Netze angeboten werden, zu be- 
obachten. Der Handel mit Waren und das Anbieten von 10 
Dienstleistungen uber elektronische Netze und insbesondere 
uber das Internet wird im allgemeinen auch als e-Commerce 
bezeichnet. 

[0003] Wahrend es haufig vom Vorteil isU sich in elektro- 
nischen Netzen anonym zu bewegen, urn keine Datenspur 15 
zu hinterlassen, verlangt gleichwohl ein GroBteil der Mog- 
lichkeiten, die bereits jetzt und auch in Zukunft elektroni- 
sche Nctzc bictcn, bestimmtc Voraussetzungen in bczug auf 
die Nachpriifbarkeit der Identitat einer Person. Dies ist be- 
sonders wichtig bei der Ubertragung von vertraulichen Da- 20 
ten, insbesondere wenn die Person ZugrifT auf fremde Daten 
haben kann. Dies gilt unter anderem auch fur den Bereich 
des e-Cominerce. 

[0004] Zu den Voraussetzungen zahlt die Gewahrlei stung 
von Sicherheit, Authentizitat und Integritat uberlragener In- 25 
formationen. 

[0005] Die Forderung nach Sicherheit der elektronischen 
Kommunikation als erste der zuvor genannten Vorausset- 
zungen folgt aus dem schlichten Umstand, daB es nur mit 
geringem Aufwand rnoglich ist, die Kommunikation und so- 30 
mit den Daten austausch zwischen zwei oder mehreren Par- 
teien abzuhoren. Ein Ausweg besteht nun darin, die Kom- 
munikation zu verschlusseln und somit fiir Dritte unlesbar 
zu mac hen. 

[0006] Mit Hilfe der Authentizitat als zweite der zuvor ge- 35 
nannten Voraussetzungen ist es ferner rnoglich, Willensau- 
Berungen einer bestimmten Person zuzuordnen. Durch die 
Authentizitat ist es fur die eine Person rnoglich, sich gegen- 
uber einer anderen Person auszuweisen oder dieser gegen- 
uber nachzuweisen, daB eine bestimmte Tatigkeit bzw. ein 40 
bestimnites Dokument von dieser einer Person durchgefiilirt 
bzw. erstellt wurde. Authentizitat wird durch eine digitale 
Signal ur hergest ellt. 

[0007] Durch die Integritat als dritte der zuvor genannten 
Voraussetzungen wird sichergestellt, daB Information, Da- 45 
ten und Dokumente nicht durch Dritte unbefugt geandert 
werden konnen, ohne daB dies bemerkbar ware. Die Integri- 
tat wird durch einen sogenannten Hashwert gewahrleistet, 
der der digitalen Signatur zugrunde liegt. 

[0008] A lie drei genannten Voraussetzungen konnen 50 
durch die Nutzung der Public-Key-Kryptographie realisiert 
werden. Hierbei besitzt jeder Nutzer ein sogenanntes 
Schliisselpaar, welches sich aus einem sogenannten Private 
Key und einem sogenannten Public Key zusammensetzt. 
Wahrend der Private Key im allgemeinen gut geschutzt ist, 55 
beispielsweise durch Verschlusselung auf einem Datentra- 
ger wie z. B. einer Chipkarte, wird der Public Key dem 
Kommunikationspartner fiir Verschlusselungszwecke zur 
Verfiigung gestellt. Beide Schlussel sind komplementar zu- 
einander; d. h. was der eine verschliisselt, kann nur von dem 60 
anderen wieder entschlusselt werden. Zum Zwecke der In- 
formations verschlusselung wird aber nur der Public Key des 
Empfangers verwendet, wahrend mil dem Private Key, den 
nur der rechtmaBige Besitzer hat, die an ihn gerichtete ver- 
schlusscltc Nachricht wicder in lesbarc Form gcbracht wcr- 65 
den kann. 

[0009] Neben der Entschlusselung wird der Private Key 
auch noch zur Signaturbildung benutzt um die Forderung 
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nach Authentizitat und Integritat zu realisieren. Bei der Si- 
gnal urbildung wird zunachsl der bereits zuvor erwahnle 
Hashwert uber die zu signierenden Daten berechnet. Auf 
diese Weise wird die Tniegrilat gewahrleistet, da eine Ande- 
rung in den signierlen Daten auch zwangslauflg zu einer An- 
derung des Hashwertes fiihrt. Dieser Hashwert wiederum 
wird mit Hilfe des Private Key des Verfassers bzw. Absen- 
ders verschliisselt. Auf diese Weise wird die Authentizitat 
gewahrleistet, da lcdiglich der rechtmaBige Besitzer uber 
den Private Key verfugt. 

[0010] Allerdings ist mit der reinen Existenz eines Private 
Key und eines Public Key noch nicht festzustellen, wem der 
Public Key, der fur Verschlusselungszwecke bereit gestellt 
wird, gehort. Um hier eine eindeutige Zuordnung zwischen 
dem Schlusselpaar und der berechligten Person vorzuneh- 
men, haben sich vertrauenswurdige Instanzen etablierl, die 
als Zenifizierungsstellen bezeichnet werden und als Dienst- 
lci stung die Idcntifizicrung von Pcrsoncn und die anschlic- 
Bende Ausstellung eines sogenannten digitalen Zertifikates 
anbieten. 

[0011] Ein digitales Zertifikat besteht aus Informationen 
uber den Zertifikatsinhaber (z. B. Name, Ort, Land, Firma, 
Abteilung, Adresse etc.), den Namen des Zertifikatsausstel- 
lers, den Gultigkeitszeitraum und den Public Key so wie aus 
der Signatur der Zerlifizierungsinslanz. 
[0012] Durch die Signatur der Zertifizierungsinstanz wird 
die Unverfalschbarkeit der im Zertifikat enthaltenen Anga- 
ben gewahrleistet. Dies ist aber nur dann sinnvoll, wenn der 
Zertifizierungsinstanz ein entsprechendes Vertrauen bei der 
AussteUung und dem Management vom Zertifikaten entge- 
gengebracht wird. 

[0013] Bei der Zertifizierungsinstanz ist die eingangs er- 
wahnte zentrale Zertifikatstatusdatenbank eingerichtet, in 
welcher der Status von samtlichen von der Zertifizierungsin- 
stanz verwalteten Zertifikaten abgespeichert ist. 
[0014] Wahrend der Gultigkeit des Zertifikates gemaB 
Gultigkeitszeitraum kann nun eine dritte Person, z. B. ein 
Anbieter von Waren und/oder Dienstleistungen, davon aus- 
gehen, daB die Angaben im Zertifikat, welches ihm vom 
Zertifikatsbesitzer vorgelegt wird, der Wahrheit entspre- 
chen, wenn sie das Zerufikat verifiziert hat. 
[0015] Allerdings kann es vorkommen, daB ein Zertifi- 
katsbesitzer seinen Daten trager (z. B. Chipkarte) mit dem 
Private Key verliert oder das der Private Key von einem 
Dritten kopiert und somit kompromittiert wurde. Um in ei- 
nem solchen unerwunschten Fall den MiBbrauch so gering 
wie rnoglich zu halten, kann der Besitzer sein Zertifikat bei 
der Zertifizierungsinstanz, von der es auch ausgestellt 
wurde, umgehend sperren (revozieren) lassen. 
[0016] Die Zertifizierungsinstanz tragt in ihrer zentralen 
Zertifikatstatusdatenbank einen Verweis auf das betreffende 
Zertifikat in eine sogenannte Sperrliste (Certificate Revoca- 
tion List, abgekurzt CRL) ein, die fur jeden offentlich zur 
Verfugung gestellt wird und dabei als Grundlage fiir eine 
Uberpriifung von Zertifikaten dient. Bei einer solchen 
Sperrliste handelt es sich dem nach um eine Negativliste, die 
nicht den gesamten Date nbe stand, sondern lediglich die ge- 
sperrten Zertifikate, in der Regel deren Seriennumniem, an- 
gibt. 

[0017] Obwohl die Sperrliste lediglich die gesperrten bzw. 
revozierten Zertifikate angibt, kann ihre GroBe zu einem 
Problem werden. So muB bei jeder Uberprufung die aktuelle 
(relevante) Sperrliste vorliegen. Da Sperrungen jederzeit 
auftreten, muB auch die Sperrliste zu jedem Zeitpunkt ent- 
sprcchend ncu erstellt werden. Um standig die aktucllcn 
Sperrinfonnationen verfiigbar zu haben, muB die Sperrliste 
bei jeder Uberprufung neu abgefragt werden. Da die Sperr- 
liste den gesamten Datenbesland samtlicher von der Zertifi- 
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zierungsstelle gespcrrten Zertifikate beinhallci, wird fur ihre 
Ubertragung cine groBe Bandbreite bendligl. 
[0018] Ein weilerer Nachteil der Spcrrliste besiehl darin, 
daB eine darauf basiercnde Aussage nur dann cine Posit iv- 
aussage isl, wenn das entsprcchende Zerti fikai tatsachlich in :> 
der Sperrlisle angegeben und somit gesperrt ist. Ansonsten 
laBt die Sperrlisle hinsichtlich der gultigen Zertifikate nur 
eine Negativaussage zu, indem der UmkehrschluB dergcstalt 
gezogen werden muB, daB das Nicht vorhandensein eines 
Zertifikales in der Sperrlisle auf dessen Giiltigkeit schlieBen 10 
laBt. Demnach isl aberbei Verwendung einer solchen Sperr- 
lisle eine Kompromittierung des Private Key der Zertinzie- 
rungsslelle oder eine unberechtigte Ausstellung eines Zerti- 
fikates nicht ohne wei teres erkennbar, da in einem solchen 
Fall das Zertifikat zumindest zunachst eine als gultig aner- 15 
kannie Signalur der Zertifizierungssleile besitzt, und zwar 
so lange, bis dieses Problem erkannt und aufgrund dessen 
das Zcrtifikat gesperrt wird. 

[0019] Eine Alternative zum Anlegen einer Sperrlisle be- 
siehl in der Bereitstellung eines Onbne-Zertifikatstatuspro- 20 
tokoll-Dienstes durch die Zertifizierungssleile. Dieser 
Dienst wird auch als Onli ne- Certificate- Statu s-Protoeol- 
Dienst oder, abgekurzt, als OCSP-Dienst bezeichnei. Mit 
diesem Dienst wird ein Protokoll zur Verfugung gestellt, mit 
den i geziell der Status einzelner Zerlifikate und Liberlicher- 25 
weise nur eines einzelnen Zertifikales uberpruft werden 
kann. Hierdurch ist es moglich, die von vielen Anwendun- 
gen geforderte Aktualitat zu gewahrieisten. Allerdings stoBt 
auch dieser Dienst bei einer hohen Anzahl zu uberpru fender 
Zertifikate schnell an die Grenzen seiner Leistungsfahigkeit. 30 
Dadurch ist dieser Dienst im Hochlastbereich nur bedingt 
einsatzfahig, zumal durch die groBe Anzahl von Abfragen 
auch hier eine entsprechende Bandbreite notwendig ist, urn 
die Antworten mit hoher Aktualitat zu versenden. 
[0020] Die beiden zuvor beschriebenen Verifikationsver- 35 
fahren decken zwei kontrare Extremfalle ab. Die Sperrliste 
eignet sich fur die Verifikalion einer hohen Anzahl von Zer- 
tifikalen, da der komplette Datenbestand der gesperrten Zer- 
lifikate vorliegt. Allerdings fiihrt hier die hohe Bandbreiten- 
belastung bei der Ubertragung des Sperrlisteninhaltes und 40 
die daraus result ierende geringere Download- Wiederiiolfre- 
quenz hciufig zu einer mangelnden Aktualitat. 
[ 0021 ] Der Online-Zertiflkatst atusprotokoll-Dienst hinge- 
gen zeichnet sich durch seine hohe Aktualitat der Statusin- 
fomiationen aus. Allerdings hat dieses Verfahren seine 45 
Grenzen dort, wo eine hohe Anzahl von Verifikationen pro 
Zeiteinheit durchgefiihrt werden miissen. Dies gilt sowohl 
fur die Recjuesiorseite (Anwender), wo die Anfrage gene- 
riert werden muB. als auch fur die Responderseite (Zertifi- 
zierungsstelle), wo die Anfrage entgegengenommen und an- 50 
schliefiend mit einer entsprechenden Antwort beantwortet 
werden muB. Zieht man weiterhin mehrere Requestoren pro 
Zerlifizierungsstelle in Betrachl, so kann sich leicht ein Vo- 
lumen von mehreren hunderi bis tausend Abfragen pro Se- 
kunde ergeben. 55 
[0022] Es ist nun Aufgabe der Erfindung, die vorteilhaften 
Eigenschaften der beiden zuvor erlaurerten Veriftkationsver- 
fahren miteinander zu verkniipfen, ohne ihre Nachteile zu 
ubemehmen. 

[0023] Diese Aufgabe wird bei einem System der Ein- 60 
gangs genannten Art dadurch gelost, daB eine Vielzahl von 
lokalen Zertifikatslatusdatenbanken geschaffen wird, die 
von auBen zugiinglich sind und als Datenbestand jeweils nur 
eine Teilmenge des Datenbesiandes der zeniralen Zertifikat- 
statusdatenbank cnthaltcn, und cine Rcplizicrcinrichtung 65 
zum Abgleich des Datenbestandes der lokalen Zertifikalsta- 
lusdalenbanken jeweils mit der entsprechenden Teilmenge 
des Datenbestandes der zentralen Zertifikatstatusdatenbank 
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vorgesehen ist. 

[0024] Mil Hilfe der Erfindung wird also ein Konzepl ge- 
schaffen, welches, ausgehend von einer zentralen Daten- 
bank bei einer Zerlifizierungsstelle, diverse lokal installierte 
Datenbanken akiualisiert. Diese lokalen Zerti fikai statu sda- 
tenbanken sind bei Kunden der Zerti fizierungsstelle einge- 
richtet, bei welchen es sich gewohnlich uni Geschafte, Ban- 
ken oder sonslige Unternehmen handelt. Mit Hilfe eines 
Prolokolls werden somit, ausgehend von der zentralen Zer- 
ti fikatstatusdalenbank bei der Zerti fizierungsstelle, die fur 
einzelne Kunden relevanten Zertifikatstatusinformationen 
mit den jeweiligen lokalen Datenbanken abgeglichen. In 
den lokalen Datenbanken wird jedoch nicht der komplette 
Datenbestand der zentralen Zertifikatstatusdatenbank, son- 
dern erfindungsgemaB nur der fur den jeweiligen Kunden 
relevante Teil repliziert Die Anderung eines Zerti fikai status 
oder im Falle einer Neuausstellung eines Zertifikales die 
Einrichtung des zugchorigen Zerti fikatstat us wird initial in 
der zentralen Zertifikatstatusdatenbank durchgefiihrt. An- 
schlieBend wird diese Anderung in die lokale Zertifikatsta- 
tusdatenbank des diese Anderung betreffenden Kunden 
ubertragen. 

[0025] Durch die erfindungsgemaBe Einrichtung vieler 
verteilter lokaler Zertifikatstatusdatenbanken kann bei der 
Zerlifikatsuberprufung ein groBes Abfragevoluiiien reali- 
siert werden. Dadurch laBt sich fur die Zertifikatstatusinfor- 
mationen eine hohe Aktualitat erzielen, so daB man fur 
samtliche Zertifikatstatusinformationen Aussagen erhalt, 
die im wesentiichen den Charakter von Positivaussagen be- 
sitzen. 

[0026] Zugriff auf die zentrale Zerti fikatstatusdalenbank 
hat nur die sie verwaltende Zertifizierungsstelle; ein ZugrifF 
von auBen, also durch andere Personen wie beispielsweise 
Kunden ist erfindungsgemaB nicht moglich. Fur den An- 
wender bzw. Kunden zuganglich ist erfindungsgemaB nur 
die ihm zugeordnete lokale Zertifikatstatusdatenbank, auf 
die selbstverstandlich auch die Zertifizierungsstelle noch zu- 
greifen kann. 

[0027] Wegen der unterschiedlichen Kundenapplikatio- 
nen sind die Datenbestande der lokalen Zertifikatstatusda- 
tenbanken selbstverstandlich unterschiedlich. Dabei handelt 
es sich erfindungsgemaB beim Datenbestand jeder lokalen 
Zertifikatstatusdatenbank jeweils urn eine Teilmenge des 
Datenbestandes der zentralen Zertifikatstatusdatenbank, und 
zwar gewohnlich derart, daB die Summe der Datenbestande 
aller lokaler Zertifikatstatusdatenbanken dem gesamten Da- 
tenbestand der zentralen Zertifikatstatusdatenbank ent- 
spricht. 

[0028] Aufgrund der erfindungsgemaBen selektiven Da- 
tenubertragung an die dezentralen lokalen Datenbanken ist 
nur eine verhaltnismaBig geringe Bandbreite erforderlich. 
Ein wesentlicher Vorteil der Erfindung in diesem Zusam- 
menhang basiert auf der Annahme, daB die Abfragen eines 
Zertifikatstatus wesentlich haufiger vorkommen als die An- 
derung oder Neuausstellung von Zerti fikaten. Die benbtigte 
Bandbreite fur die Nutzung eines Verifikationsdienstes kann 
somit drastisch gesenkt werden, da lediglich der Status der 
lokalen Datenbank und nicht jedes einzelne Zerti fik at in der 
zentralen Zertifikatstatusdatenbank uberpruft wird. Auf 
diese Weise laBt sich ein nahezu beliebiges Verifikationsvo- 
lumen bei relativ geringer Bandbreite realisieren. 
[0029] AuBerdem lassen sich mit Hilfe des erfindungsge- 
maBen Systems Zertifikate erkennen, die mit einem kompri- 
mettierten Zerti fizierungsstellenschlussel erstellt worden 
sind, da dcrartigc Zertifikate zwar cine giiltig schcincndc 
Zerti fizierungsstellensignatur besitzen, aber nicht in die zen- 
trale Datenbank der Zertifizierungsstelle eingetragen wor- 
den sind. Dies hat zur Folge, daB auch solche gullig schei- 
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ncnden, tatsachlich jedoch gefalschlen Zertifikate bei eineni 
Update unberucksichtigi bleiben und daher audi nichl von 
der Kundenapplikalion als guitig betrachtet werden. 
|0030] SchlicRlich besitzi das erfindungsgeniaBe System 
noch den Vorteil der Skalierbarkeil an die Bedurfnisse des 5 
jeweiligen Kunden. 

[0031] Die Repliziereinrichtung sollte den Datenbestand 
mindestens einer LokaJen Zertifikatstatusdatenbank in be- 
stimmlen, vorzugsweise gleichmaBigen, Zeitiniervallen mil 
der entsprechenden Teilmenge des Dalenbestandes der zen- 10 
tralen Zertifikatstatusdatenbank wiederholt vergleichen. 
[0032] ZweckmaBigerweise iiberpruft die Repbzierein- 
richtung, vorzugsweise regelmaBig, den Datenbestand der 
zenlralen Zertifikatstatusdatenbank auf Anderungen und ak- 
tualisiert nur dann den Datenbestand einer lokalen Zertifi- 15 
katstatusdatenbank, wenn sie in der entsprechenden Teil- 
menge des Dalenbestandes der zen tralen Zertifikatstatusda- 
tenbank Anderungen rest stc lit. Mit dieser Ausfiihrung laBt. 
sich eine besonders hohe Aktualitat der Zertifikatstatusin- 
formationen erzielen, wahrend nur eine verhaltnismaBig ge- 20 
ringe Bandbreite bei der Ubertragung benotigt wird, da nur 
bei Bedarf eine Aktualisierung der lokalen Zertifi kats tat us- 
datenbanken vorgenommen wird. 

[0033] Gewohnlich weisl die Repliziereinrichtung einen 
Server und ein NeLzwerk auf, iiber das die lokalen Zerti fikat- 25 
statusdatenbanken mit der zentralen Zertifikatstatusdaten- 
bank verbunden sind. Die Repliziereinrichtung kann auch 
Teil eines vorhandenen Netzwerkes mit Server sein oder 
auch im Server eines Netzwerkes enthalten sein. Der Server 
steuert das Netzwerk und befindet sich uberlicherweise bei 30 
der Zertifizierungsstelle. Dabei ubertragt das Netzwerk An- 
derungen einer Teilmenge des Dalenbestandes der zentralen 
Zertifikatstatusdatenbank an die zugehorige lokale Zertifi- 
katstatusdatenbank. Altemativ kann die Repliziereinrich- 
tung aber auch bei spiel sweise in der zentralen Zertifikatsta- 35 
tusdatenbank enthalten sein; es ist aber auch denkbar, die 
Repliziereinrichtung verteilt in den lokalen Zertifikatstatus- 
datenbanken vorzusehen. 

[0034] Eine weitere gegenwartig besonders bevorzugte 
Ausfiihrung der Erfindung zeichnet sich dadurch aus, daB 40 
die Repliziereinrichtung von der zentralen Zertifikatstatus- 
datenbank zu den lokalen Zerti fikatstatusdatenbanken Up- 
date-Nachrichten iibermittelt, die mit einer Sequenznummer 
versehen sind und Zerti fikationsinformationen, wie z. B. Se- 
riennummer, Fingerprint^ Zertifi katstatus und/oder Datum 45 
des aktuellen Status, enthalten. 

[0035] Ublicherweise werden hierzu Protokolle ubermit- 
telt, die bestimmte Protokollelemente enthalten, von denen 
ein Protokollelement aus der zuvor erwahnten Update- 
Nachricht besteht. 50 
[0036] Bei einer Weiterbildung der zuvor erwahnten Aus- 
fiihrung der Erfindung fragt die Repliziereinrichtung in der 
betreffenden lokalen Zertifikatstatusdatenbank die Sequenz- 
nunimer der zuletzt empfangenen Update-Nachricht ab und 
vergleicht diese mit der Sequenznummer der zuletzt an diese 55 
lokale Zertifikatstatusdatenbank ubertragenen Update- 
Nachricht in der zentralen Zertifikatstatusdatenbank und 
ubermittelt nur im Falle einer Ubereinstimmung eine nach- 
ste Update-Nachricht von der zentralen Zertifikatstatusda- 
tenbank an die betreffende lokale Zertifikatstatusdatenbank. 60 
Auf diese Weise laBt sich die Aktualitat der betreffenden lo- 
kalen Zertifikatstatusdatenbank verifizieren. Fur diese MaB- 
nahme bietel sich insbesondere die Verwendung eines Ping- 
Request und einer zugehorigen Ping-Response an. Urn nam- 
lich den Empfang cincr Update-Nachricht zu bestatigen, 65 
wird vom Kunden bzw. von dessen lokaler Zertifikatstatus- 
datenbank ein Ping-Request mit der Sequenznummer der 
zuletzt empfangenen UpdauvNachricht an den Server der 
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Zertifizierungsstelle verschickt. Auf diesen Ping-Request 
ant worlet der Server der Zertifizierungsstelle mit einer Ping- 
Response, die die Sequenznumnier der zuletzt ubertragenen 
Update-Nachricht enthalt und somit die Aktualitat der loka- 
len Zertifikatstatusdatenbank des Kunden bestatigt. 
[0037] Weiterhin kann der zuvor erwahnte Ping-Request 
dazu dienen, sogenannle "Denial-of- Service"- Attacken zu 
erkennen, wenn die entsprechende Ping-Response oder Up- 
date-Nachricht nicht innerhalb eines vorbestimmten Zeitin- 
tervalls bzw. Timeouts zugestellt werden kann. 
[0038] Das aus Ping-Request und Ping-Response beste- 
hende Prolokollpaar stellen die am haufigsten genulzten 
Protokollelemente dar, da ublicherweise die Bestatigung der 
Aktualitat einer Datenbank wesentlich haufiger iiberpruft 
wird, als sich Anderungen oder Neuausstellungen von Zerti- 
fikaten ergeben. 

[0039] Ferner kann eine Verifizierungseinrichtung zur, 
vorzugsweise rcgclmaBigcn, Ubcrprufung der Intcgritat der 
Datenbestande der lokalen Zertifikatstatusdalenbanke vor- 
gesehen sein, um eine (lokale) Manipulation zu erkennen 
und ggf. den Neuaufbau der betreffenden Datenbank zu ver- 
anlassen. 

[0040] Ublicherweise vergleicht die Verifizierungsein- 
richtung die Datenbestande der lokalen Zertifikatstatusda- 
lenbanke mil dem Datenbestand der zenlralen Zerlifi katsta- 
tusdatenbank. Ahnlich wie die Repliziereinrichtung kann 
auch die Verifizierungseinrichtung einen Server und ein 
Netzwerk aufweisen oder im Server eines Netzwerkes ent- 
halten sein. Ferner ist es aber auch denkbar, die Verifizie- 
rungseinrichtung zentral bei der Zertifizierungsstelle und so- 
mit vorzugsweise in der zentralen Zertifikatstatusdatenbank 
oder altemativ verteilt in den lokalen Zertifikatstatusdaten- 
banken vorzusehen. 

[0041] Eine gegenwartig besonders bevorzugte Weiterbil- 
dung der zuvor genannten Ausfiihrung der Erfindung zeich- 
net sich dadurch aus, daB die Verifizierungseinrichtung eine 
Verifizierungsanforderung einer lokalen Zertifikatstatusda- 
tenbank an die zentrale Zertifikatstatusdatenbank ubermit- 
telt, dann von dieser an die betreffende lokale Zertifikatsta- 
tusdatenbank eine Verifizierungsantwort zuriicksendet, die 
vorzugsweise einen Hashwert iiber Seriennummer, Finger- 
print, Zerufikatstatus und/oder Daten des aktuellen Status 
enthalt. und anhand dieser Verifizierungsantwort in der lo- 
kalen Zertifikatstatusdatenbank iiberpruft, ob deren Daten- 
bestand mit der entsprechenden Teilmenge des Datenbestan- 
des der zentralen Zertifikatstatusdatenbank ubereinstimmt. 
Anhand dieses Hashwertes kann auf Kundenseile bzw. auf 
seiten der betreffenden lokalen Zertifikatstatusdatenbank 
iiberpruft werden, ob der dortige Zertifikatstatusdatenbe- 
stand mit dem von der Zertifizierungsstelle verwalteten Ori- 
ginal identisch ist, indem bei der Zertifizierungsstelle nur 
die fur den betreffenden Kunden bzw. die betreffende lokale 
Zertifikatstatusdatenbank relevante Teil betrachtet wird. 
[0042] Die zuvor erwahnte Verifizierungsanforderung, 
auch Verify-Request genannt, und die Verifizierungsant- 
wort, auch Verify-Response genannt, bilden weitere Proto- 
kollelemente im zu ubermittelnden Protokoll. Verifizie- 
rungsanforderungen konnen in regelmaBigen Abstanden ge- 
stellt werden, um neben der Aktualitat, die durch das zuvor 
erwahnte Ping-Request- und Ping-Response-Paar gewahr- 
leistet wird, die Integritat der lokalen Zertifikatstatusdaten- 
bank des betreffenden Kunden nachweisbar zu halten, 
[0043] Auch bei Fehlern im ubermittelten Protokoll und/ 
oder sonstigen verdachtigen Situationen, die auf einen mog- 
lichcn Vcrlust der Intcgritat hinweisen, kann cine Verifizie- 
rungsanforderung gestellt werden. 

[0044] Sollte bei der Verifizierung eine Unslimmigkeit 
aufgetreten sein - beispielsweise enthalt die betreffende lo- 
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kale Zenifikatsiatusdaienbank nichi diejenigen Dalcn, die 
sie gemaC der Zerlifizierungsslellc enlhallen solhe - und ist 
dies nicht lediglich durch eincn Verlusl von Update-Nach- 
riehlen hegriindel. so wird vom Kundcn, also von seiien der 
belief fenden lokalen Zertitikatstaiusdalenbank, cine koni- 5 
plelle Neuerslellung des dort.igen Dalenbesiandes veranlafil. 
Fur die komplette Neuerslellung sendet der Kunde bzw. des- 
sen lokaie Zertirikatslatusdalenbank eine Full-Update-An- 
forderung oder -Request an dicZenihzierungsstelle, die dar- 
aufhin den kompleiten Datenbesiand gemafi der entspre- 10 
chenden Teilmenge des Dalenbesiandes der zentralen Zerti- 
nkalsiatusdatenbank durch eine spezielle Update-Nachricht 
Libert ragt. 

[0045] Nachfolgend wird ein bevorzugles Ausfuhrungs- 
bei spiel der Erfindung an hand der beiliegenden einzigen Fi- 15 
gur nalier erlautert, inder ein schematisches Blockschaltbild 
einer bevorzugten Ausfuhrung eines Systems zur St at us ab- 
fragc von digilalcn Zcrtifikatcn dargcstcllt ist. 
[0046 J Hiernach ist bei einer Zertifizierungsstelle 2 eine 
zenlrale Dalenbank 4 installiert, in welcher samtliche von 20 
der Zenifizierunginstanz 2 verwalleten Zerti fi kate und deren 
Status abgespeichert ist. Ein - vorzugsweises digiiales - 
Zertifikat besteht. aus Informationen uber den Zerti fikatsin- 
haber (z. B. Name, On, Land, Finna, Abteilung, Adresse 
etc.), den Nanien des Zerti fikalsauss tellers, den Gulligkeits- 25 
zei trau in und den Public Key sowie aus der Signatur der 
Zertifizierungsinstanz 2. 

[0047] Femer weist die Zertifizierungsinstanz 2 einen Ser- 
ver 6 auf, der die zentrale Dalenbank 4 mil einem Netzwerk 
8 verbindet. Das Netzwerk 8 besteht ublicherweise aus re- 30 
servierten Standleitungen, auf die Dritte keinen Zugriffha- 
ben. Aus Sicherheitsgrunden sollte das Internet als Netz- 
werk d age gen nicht unbedingt genutzt werden. 
[0048] Die Kunden der Zertifizierungsinstanz 2 sind uber 
das Netzwerk 8 unit der Zertifizierungsinstanz 2 verbunden. 35 
Bei jedem Kunden ist mindestens ein Client 10 und eine 
daran angeschlossene lokaie Dalenbank 12 installiert. 
[0049] In den lokalen Datenbanken 12 ist jeweils nur eine 
fiir den jeweiligen Kunden relevante Teilmenge des Dai en- 
best andes der zentralen Dalenbank 4 abgespeichert. 40 
[0050] Mil Hilfe des Servers 6 werden uber das Netzwerk 
8, ausgehend von der zentralen Datenbank 4, die bei den 
Kunden installiert en lokalen Datenbanken 12 aktualisiert. In 
den lokalen Datenbanken 12 wird jedoch nicht der kom- 
plette Datenbestand der zentralen Datenbank 4, sondern nur 45 
der fiir den jeweiligen Kunden relevante Teii repliziert. Da- 
bei wird die Anderung eines Zertifikat status oder die Neu- 
ausstellung von Zertifikaten initial in der zentralen Daten- 
bank 4 der Zertifizierungsinstanz 2 vollzogen, und anschlie- 
Bend wird diese Anderung in die lokaie Datenbank 12 des an 50 
dieser Anderung interessierten Kunden iibertragen. 
[0051] So wird ein bestimmt.es Protokoll verwendet, mit 
dem, ausgehend von der zentralen Datenbank 4 bei der Zer- 
tifizierungsinstanz 2, die fur die einzelnen Kunden relevan- 
ten Zerl.ifikat.stat.us mi t den jeweiligen lokalen Datenbank 12 55 
abgeglichen werden. Dieses Protokoll besteht im Einzelnen 
aus folgenden element aren Nachrichten: 

1. Update-Nachricht 

60 

[0052] Ein Protokollelement mit dem, ausgehend von der 
zentralen Datenbank 4, die lokalen Datenbanken 12 aktuali- 
siert werden, ist die Update-Nachricht. Eine Update-Nach- 
richt ist mit einer Sequenznummer versehen und enthalt 
Zcrtifikatinfomiationcn wic z. B. Scricnnummcr, Finger- 65 
print, Zertifikat st at us und Datum des aktuellen Status. 



2. Ping-Request/Ping-Response 

[0053] Uni die Aktualitat seiner lokalen Datenbank 12 zu 
verifiziercn und den Empfang einer Updale-Nachricht zu 
bestatigen, wird vom Client 10 des Kunden ein Ping-Re- 
quest mil der Sequenznummer der zuletzt. empfangenen Up- 
date-Nachricht an den Server 6 der Zertifizierungsinstanz 2 
verschickl. Auf den Ping-Request ant.wort.et. der Server 6 der 
Zertifizierungsinstanz 2 mit einer Ping-Response, die die 
Sequenznummer der zuletzt ubertragencn Update-Nachricht 
enthalt und somit die Aktualitat der Kundendatenbank be- 
statigt. 

[0054] Weiterhin dient der Ping-Request dazu, "Denial- 
of-Service"-Attacken zu erkennen, wenn die entsprechende 
Ping-Response bzw. Update-Nachricht nicht innerhalb eines 
Timeouts zugestellt werden kann. 

[0055] Das Protokollpaar, bestehend aus Ping-Request 
und Ping-Rcsponsc, stcllt. den Norm alf all dar und bildct die 
am haufigsten genutzten Protokollelemente, da die Bestati- 
gung der Aktualitat. einer Datenbank wesentlich haufiger 
iiberpruft wird, als sich Anderungen und Neuausstellungen 
von Zertifikaten ergeben. 

3 . Veri fy-Req u est/ Veri ly-Respon se 

[0056] Die Protokollelemente Verity-Request und Verify- 
Response sind darauf ausgelegt, die Integritat aller Daten- 
banken 4 und 12 zu uberprufen. eine (lokaie) Manipulation 
zu erkennen und ggf. den Neuaufbau einer Datenbank zu 
veranlassen. 

[0057] Auf einen Verify-Request einer lokalen Dalenbank 
12 uber den zugehorigen Client 10 erfolgt eine Verify- Re- 
sponse der Zertifizierungsinstanz 2 von der zentralen Daten- 
bank 4 uber den Server 6, welcher einen Hash uber die Seri- 
ennummer, den Fingerprint, den Zerti fikatstat.us und das Da- 
tum des aktuellen Status aller fur den entsprechenden Kun- 
den relevanten Z^ertifikate enthalt. Anhand dieses Hash-Wer- 
tes kann dann auf Kundenseite iiberpruft werden, ob dessen 
gesamter Zertifikatsdatenbestand in der zugehorigen lokalen 
Datenbank 12 mil dem in der zentralen Datenbank 4 der 
Zertifizierungsinstanz 2 abgespeicherten und dort verwalte- 
ten Original identisch ist. Hierbei wird auch bei der Zertifi- 
zierungsinstanz 2 nur der fur den jeweiligen Kunden rele- 
vante Teil betrachtet. 

[0058] Verify-Requests konnen in regelmaBigen Abstan- 
den gestellt werden, um neben der Aktualitat. die durch das 
Ping-Request und Ping-Response-Paar gewahrleistet wird, 
auch die Integritat der lokalen Datenbanken 12 nachweisbar 
zu halten. 

[0059] Auch bei Protokollfehlem und sonstigen verdach- 
tigen Situationen, die auf einen moglichen Verlust der Inte- 
gritat hinweisen, kann ein Verify-Request gestellt werden. 
[0060] Sollte hierbei eine Unstimmigkeit aufgetreten sein, 
d. h. die lokaie Datenbank 12 des jeweiligen Kunden nicht 
die Daten en t halten, die sie gemafi der Zertifizierungsin- 
stanz 2 haben sollte, und liegt dies nicht am Verlust von Up- 
date- Nachrichten, so wird vom Kunden eine komplette Neu- 
erstellung der zugehorigen lokalen Datenbank 12 initiiert. 

4. Fullupdate-Request 

[0061] Fur die komplette Neuerslellung sendet der Kunde 
uber seinen zugehorigen Client 10 einen Fullupdate-Request 
an den Server 6 der Zertifizierungsinstanz 2, woraufhin der 
Server 6 den fur dicscn Kunden relevanten Tcil des Datcn- 
bestandes aus der zentralen Datenbank 4 durch eine spe- 
zielle Update-Nachricht an die entsprechende lokaie Daten- 
bank 12 des Kunden ubertragt. 
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Patent an spriiche 

1 . System zur Statu sabf rage von digital en Zerti hkalen, 
mil einer zentralen Zertifikatslatusdatenhank (4), ge- 
kennzeichnet durcli eine Vielzahl von lokalen Zertifi- 5 
katstatusdatenbanken (12), die von auBen zuganglich 
sind und als Datenbesland jeweils nur eine Teilmenge 
des Datenbestandes der zentralen Zerti fikatstatusdal en- 
bank (4) entbalten, und eine Repliziereinrichtung (6, 8, 
10) zum Abgleich des Dalenbestandes der lokalen Zer- 10 
tifikatstatusdatenbanken (12) jeweils mit der entspre- 
chenden Teilmenge des Datenbestandes der zentralen 
Zerti fi kat statu sd at enban k (4) . 

2. System nach Anspruch 1, dadurch gekennzeichnet, 
daB die Repliziereinrichtung (6, 8, 10) den Datenbe- 15 
stand mindestens einer lokalen Zerti fikatstatusdat en- 
bank (12) in besrimmten, vorzugsweise gleichmaBigen, 
Zcitintcrvallcn mit dor cntsprcchcndcn Teilmenge des 
Datenbestandes der zentralen Zertifi katstatusdaten- 
bank (4) wiederholt abgleicht. 20 

3. System nach Anspruch 1 oder 2, dadurch gekenn- 
zeichnet, daB die Repliziereinrichtung (6, 8, 10), vor- 
zugsweise regelmaBig, den Datenbestand der zentralen 
Zertifikatstatusdatenbank (4) auf Anderungen uber- 
prlifl und nur dann den Datenbesland einer lokalen Zer- 25 
tifikatstatusdatenbank (12) aktualisiert, wenn sie in der 
entsprechenden Teilmenge des Datenbestandes der 
zentralen Zertifikatstatusdatenbank (4) Anderungen 
feststellt. 

4. System nach mindestens einem der Anspriiche 1 bis 30 
3, dadurch gekennzeichnet, daB die Repliziereinrich- 
tung einen Server (6) und ein Netzwerk (8) aufweist, 
uber das die lokalen Zertifikatstatusdatenbanken (12) 
mit der zentralen Zertifikatstatusdatenbank (4) verbun- 
den sind. 35 

5. System nach Anspruch 4, dadurch gekennzeichnet, 
daB das Netzwerk (8) Anderungen einer Teilmenge des 
Datenbestandes der zentralen Zertifikatstatusdaten- 
bank (4) an die zugehorige lokale Zertifikatstatusdaten- 
bank (12) ubertragt. 40 

6. System nach mindestens einem der Anspriiche 1 bis 
5, dadurch gekennzeichnet, daB die Repliziereinrich- 
tung (6, 8, 10) von der zentralen Zertifikatstatusdaten- 
bank (4) zu den lokalen Zertifikatstatusdatenbanken 
(12) Update-Nachricht en ubermittelt, die mit einer Se- 45 
quenznummer versehen sind und Zertifi kationsinfor- 
mationen, wie z. B. Seriennummer, Fingerprint, Zerti- 
fikatst.at.us und/oder Daten des aktuellen Status, enthal- 
ten. 

7. System nach Anspruch 6, dadurch gekennzeichnet, 50 
daB die Repliziereinrichtung (6, 8, 10) in der betreffen- 
den lokalen Zertifikatstatusdatenbank (12) die Se- 
quenznurnmer der zuletzt empfangenen Update-Nach- 
richt abfragt und mit der Sequenznummer der zuletzt 

an diese lokale Zertifikatstatusdatenbank (12) ubertra- 55 
genen Update-Nachricht in der zentralen Zertifikatsta- 
tusdatenbank (4) vergleicht und nur irn Falle einer 
Ubereinstimmung eine nachste Update-Nachricht von 
der zentralen Zertifikatstatusdatenbank (4) an die be- 
treffende lokale Zertifikatstatusdatenbank (12) uber- 60 
mitte It. 

8. System nach mindestens einem der Anspriiche 1 bis 
7, gekennzeichnet durch eine Verifizierungseinrichtung 
(6, 8, 10) zur, vorzugsweise regelmaBigen, Uberprti- 
fung dor Intcgritat der Dalcnbcstandc der lokalen Zerti- 65 
fi katstatusdatenbanken (12). 

9. System nach Anspruch 8, dadurch gekennzeichnet, 
daB die Verifizierungseinrichtung (6, 8, 10) die Daien- 
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bestandc der lokalen Zertifi katstatusdatenbanken (12) 
mil dem Datenbestand der zentralen Zertifikatstat usda- 
tenbank (4) vergleicht. 

10. System nach Anspruch 9, dadurch gekennzeichnet, 
daB die Verifizierungseinrichtung (6, 8, 10) eine Verifi- 
zierungsanforderung einer lokalen Zertifikatstatusda- 
tenbank (12) an die zentrale Zertifikatstatusdatenbank 
(4) ubermittelt, dann von dieser an die betreftende lo- 
kale Zertifikatstatusdatenbank (12) eine Verifizierungs- 
anwort zururcksendet, die vorzugsweise einen 
Hashwert uber Seriennummer, Fingerprint, Zerti fikat- 
status und/oder Daten des aktuellen Status enthalt, und 
anhand dieser Verifizierungs ant wort in der lokalen Zer- 
tifikatstatusdatenbank (12) uberpruft, ob deren Daten- 
bestand mit der entsprechenden Teilmenge des Daten- 
bestandes der zentralen Zertifikatstatusdatenbank (4) 
ubereinstimmt. 
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